1. Technical Field
The present disclosure relates generally to systems and methods for calculating alerts and, more particularly, to systems and methods for calculating alerts based on pegging.
2. Description of the Background Art
Supply chain planning (SCP) is used today by many manufacturing companies. SCP can be used, for example, to ensure that supplies used in manufacturing an end product are timely delivered so that a customer's order can be timely filled. SCP can involve many aspects of the manufacturing process from making sure that adequate supplies are available to making sure that transportation of the finished product to the customer takes place in a timely and efficient fashion.
Applications are used in the supply chain that create and dynamically alter steps in the supply chain in response to changes in demands and capacity. To ensure the fast and efficient operation of the supply chain, the applications need quick and easy access to data relating to the flow of materials through the supply chain. The way in which this data is stored determines how easily it can be accessed.
Supply chain data is often stored in multiple relational database tables. In early supply chain planning systems, if a part of a manufacturing order was changed, all aspects of the supply chain effected by the change would be recalculated using the data in the relational database tables. However, in early systems, since the information had to be traced through the relational database tables, the systems were cumbersome and unnecessarily delayed planning functions.
Systems were thus developed to store all data relevant to supply chain planning in an efficient manner reflecting the progress of materials and orders along the supply chain. An example of such a system is shown in FIG. 2A. Order 10 represents an organizational unit that groups together several activities 11. Each order points to the first activity and the last activity of its activity network. Thus, order 10 points to activity 12 and activity 13. Each activity 11 contains a reference 14 to its corresponding orders. As shown in FIG. 2B, related activities such as a chain of activities 11a, 11b and 11c that must be executed in order may be grouped together into an operation 20 to avoid having to map each activity individually on a planning table.
Referring now to FIG. 2C, each order 10 may have one or more input interface nodes 30 and/or one or more output interface nodes 31. Each input interface node 30 represents a material used in fulfilling the order. An input interface node 30 may also include attribute information as to the quantity of the material required, the time requirement of the material and may indicate a shortage of the material. A shortage of a material can be determined, for example, by determining the difference between the quantity of material required and the quantity that is delivered by other orders or stock. Each output interface node 31 also has attributes. These attributes can include the type of material created, the quantity of material created, the time availability of the material and the surplus of the material, if any. Each input interface node 30 may refer to the activity 12, if any, in which the material that it represents is consumed, and each output interface node 31 points to the activity 13, if any, in which the material that it represents is created. If an activity 12 consumes a material, all input materials of this activity can be traced via arrows marked with dashes and dots 32a that point from activity 12 to input interface node 30. If input activity 12 consumes more than one material, arrow 32b joins input interface node 30a to the next input interface node 30b, which links on the same input activity 12.
“Pegging” links two orders when one of the orders supplies a material consumed by the other order. Pegging tracks the type and quantity of material supplied by a subordinate order to a superior order. Pegging thus allows planners to ascertain the superior and subordinate orders for any given order at any given time. If the planner reschedules the dates of an order, pegging allows all other orders influenced by the change to be updated.
FIG. 3 illustrates an example of pegging between orders, consisting of 12 orders 201-212 that produce or consume materials M1, M2 and/or M3. For example, as shown one un it each of M2 and M3 are used to produce each unit of M1. Next to each input interface node 30 is the type of material 44, the required quantity 40 and the requirements date 41 for the material. For example, order 201 utilizes 60 units each of M2, M3 which are required by May 11, 2006. Next to each output interface node 32 is the type of material 54, the quantity created 50 and the availability date 51 for the material. For example, order 208 produces 100 units of M2 which are available Apr. 22, 2006. Relationships between orders can be mapped with pegging arcs, as shown. For example, the orders which supply order 201 can be found by starting from input interface node 30 of order 201 and alternately following the solid curved arrow lines 52 and the dashed curved arrow lines 53 to output interface node 32 of order 208. Similarly, the orders that supply order 202 can be found by starting from the input interface node 30 of order 202 and alternately following the solid curved arrow lines 54 and the dashed curved arrow lines 55 to output interface node 32 of order 208. The orders which order 209 supplies can be found by starting from output node 32 of order 209 and alternately following solid straight arrow lines 56 and dashed straight arrow lines 57 to input node 30 of order 203 and solid straight arrow line 58 and dashed straight arrow line 59 to input node 30 of order 204. The values shown in nodes 57 represent the quantity of materials being provided by an order. For ease of description, orders supplying M3 are omitted and only orders supplying M2 are shown. Of course, it will be appreciated that in reality, pegging arcs can also be shown for orders supplying M3, either separate from or together with the orders supplying M2.
Pegging is thus always global and essentially matches supply and demand. Accordingly, although pegging can link a large network of orders, pegging in this way also requires that all demands for materials be matched to all outputs of the materials. In order to do this, all orders and materials have to be considered. Accordingly, it can be difficult to determine when material supply may come up short, particularly in high volume situations when many orders are involved.
Alerts can be used to notify an operator when material supply comes up short. Alerts can be calculated on deviation in quantity. For example, a lateness alert is based on pegging. To properly perform pegging, all inputs and outputs have to be taken into account. Present systems read all input nodes and output nodes and calculate pegging and alerts using the information. However, reading all input and output nodes and calculating pegging and alerts based thereon can be time consuming and require a large amount of memory. If many orders are involved, pegging and/or alerts can be particularly difficult to show to a user in a meaningful manner.
Accordingly, there is a need to provide a system that enables information to be presented to a user that is meaningful and useful.